「それコンテナにする意味あんの？」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019

「どのアプリケーションをコンテナ化するべきか？」「コンテナを何をつかって運用するか？」という疑問に、真正面から解説してみました。皆様のコンテナワークロード選択の一助になれば幸いです。

Developers.IO 2019 OKAYAMA

#Amazon ECS

#コンテナ

#AWS Fargate

#Amazon EKS

#AWS

濱田孝治

2019.04.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんコンテナを使うことの意味を自信もって答えられるでしょうか？

ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。

「それはコンテナ化する意味があるの？」
「こんなコンテナ運用は危ない？」
「ECSの設定とか実際めんどい。docker runじゃだめ？」
「EKSって使えんの？」

そういう声を聴く中で、自分なりの答えを模索していたわけですが、岡山での弊社イベントAWS最新技術の祭典Developers.IO 2019 at 岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。

「このアプリをコンテナ化する意味があるのか、わからない」
「コンテナ化することで余計めんどくさくなった」
「AWSのコンテナサービスの何を使ったら良いのかわからない」

という悩みを抱えている方には、是非一度こちらの内容を見て、ヒントを掴んでいただければと想います。

（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     ｺﾝﾃﾅ ﾀﾉｼｸ ﾔﾘﾏｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

発表資料

こちらから参照できます。

迷える子羊に捧げるコンテナ環境徹底比較　〜ECS、Fargate、EKSは何が得意で不得意か〜 - Speaker Deck

導入「迷いないコンテナ運用を目指して」

みなさん、コンテナ使っていますか？本日お話することは、一言、こちら。

45分という短い時間なので、コンテナやAWS関連サービスの細かい技術要素の話はしません。どちらかというと、これからコンテナを導入してみようという人であったり、コンテナの運用に苦労している方に向けたセッションとなります。

それでは、「迷いないコンテナ運用を目指して」をテーマに始めていきます。

本日の話の流れは以下の通りです。

「コンテナとは何かを理解する」

最初に、コンテナそのものについて振り返りましょう。コンテナ型仮想化技術を図示したものがこちら。

一般的には仮想化ソフトウェアを使わずにOSのリソースを隔離するので、起動のオーバーヘッドが少ないのが従来の仮想化技術との差別化要素です。

Dockerを使うには、何がなくともDockerのインストールが必要です。こちら（Docker Desktop for Mac and Windows | Docker）からインストールしてみましょう。

一番最初に試してみて頂きたいのがこちら。Pandocというプロダクトを使ってmarkdownファイルをWord（docx）に変換します。1行です。Dockerインストールするだけでこれが動きます。

sample.mdからsample.docxを作るコマンドがこちら。

$docker run -v `pwd`:/source jagregory/pandoc -f markdown -t docx sample.md -o sample.docx

Pandocのインストールも何もしていないのに、いきなり文書変換できる理由がこちら。

ここで、Dockerの使い方として覚えていただきたいことは、DockerはCLIっぽく使えるということです。なので、従来の仮想化技術とは利用用途がかなりことなります。

自分好みのイメージを作るには、Dockerfileを作る必要があります。

Dockerfileの凄いところは「インフラのプロビジョニングからアプリケーションのインストールまで、一つのテキストファイルで記述できる」点です。

従来のEC2インスタンスをたてて、動かした場合との比較した表がこちら。

インフラをコードで管理するのが最近のトレンドですが、コンテナの場合は、全てDockerfileで完結します。

Dockerfileを書いたり、container buildを極めたい方は、ぜひこちらの資料を御覧ください。

「コンテナを使う意味を考える」

そこにアプリケーションがあり、コンテナ化を迷った時の判断基準として必ず抑えておくべきなのは以下の3つです。

私の個人的な感触ですが、このうち2つ以上YESなら、コンテナ化を検討してみましょう。

対して、コンテナ運用するには非常に微妙な例として、GitLabについて紹介します。

GitLab CE、インストール方法は複数あるんですが、長きに渡って運用する場合、やらないほうが良いインストール方法があります。それがこちら。

Docker Imageを利用したインストールって確かに簡単なんですね。ただ、それをきちんと長きに渡って運用していくとき、常にコンテナの中に状態をもつアプリケーションの運用は、はっきり言ってDockerには向いていません。普通にEC2で運用したほうが、絶対安定します。

先程の判断基準は、具体的なユースケースに基づいています。これらが必要な場合は、コンテナ化することのメリットは非常に大きくなります。

複数の環境でつかうか？
開発〜検証〜本番で同じイメージを使う
頻繁に変更するか？
どんどん機能追加をしていきたい
増えたり減ったりするか？
負荷に応じて弾力的に数を変えたい

アプリケーションをコンテナ化するときの指針はあります。まずは一番定番で王道なのがこちら。

The Twelve-Factor App （日本語訳）

もうすこし、Docker向けに焦点を絞っているのがこちら。

[AWS Black Belt Online Seminar] Docker on AWS レポート [12-factor App] ｜ DevelopersIO

これらの情報は是非一通り目を通しておいてほしいのですが、重要なポイントを抜粋するとこうなります。もし、アプリケーションがこれを満たしていないのであれば、Dockerfileを作り始める前にこの対応をしましょう。

「AWSにおけるコンテナについて理解する」

AWSにおけるコンテナサービスを区別すると、まずはこうなります。

ECR（Amazon Elastic Container Registry）とは

その他のサービスについて説明していきますが、まず最初にお知らせしておきたいのはこちら。

ので、AWSのコンテナサービス郡を最初に理解するためには、コントロールプレーンとデータプレーンについて理解する必要があります。

コントロールプレーンとデータプレーン

コントロールプレーンとは、コンテナの管理をする場所

動く場所の管理
VPC、Subnet、Load Balancer、Security Group
コンテナ生死の管理
監視設定、自動復旧
コンテナ数の管理
負荷に応じたコンテナ数のオートスケール

データプレーンとは、実際にコンテナが稼働する場所

コントロールプレーンからの指示にしたがって起動
コンピューティングリソースを消費（従量課金対象）
状態をコントロールプレーンに通知

これらの関係性を図示するとこうなります。

今のサービス名とラベリングするとしたらこうなりますね。今回のセッションでも、この前提でお話していきます。

ECS（Amazon Elastic Container Service）とは

AWS完全マネージドのコンテナオーケストレーションツールです。

簡単なオートスケール設定
ロードバランサー統合
コンテナのIAM権限管理
コンテナのセキュリティグループ管理
CloudWatch メトリクス統合
CloudWatch Logs統合
スケジュール実行機能

最大の特徴は、元がAWSフルマネージドなサービスのため、他のAWSサービスとの連携が簡単という点です。

ただ、ECSの内部構造は決して簡単ではないです。ので、ここでは図示して一つずつ説明していきます。

まず、タスク定義とコンテナ定義の構造がこちら。

コンテナ定義には、各コンテナ単位での設定情報（ほぼ、Docker run時に設定できる内容）が含まれており、それらを統合してタスクとしてハードウェアリソースを割り当てます。

1タスクに複数コンテナを割り当てる代表的な例をあげます。

さらに、クラスターとサービスの関係性がこちら。クラスターが全体的なサービスを論理的に統合し、サービスには、タスク定義から具体的にサービス提供するためのインフラ周辺の情報を登録することになります。

実際にこれを、先程のタスク定義例で動かしたときの動作イメージがこちら。

EKS（Amazon Elastic Container Service for Kubernetes）とは

AWSマネージドなKubernetesサービス

正式名称はAmazon Elastic Container Service for Kubernetes
Kubernetes正式準拠
Kubernetesコミュニティが作成した既存のプラグインやツールを利用できる

最大の特徴は、元がオープンソースプロダクトなため、Kubernetes用に開発されたツールを広く使うことができるという点です。

具体的には、Kubernetesのコントロールプレーン、ここをマネージドとして提供しているのがEKSです。

こちらのデータプレーンは、EC2で提供され、実際の構築はCloudFormationなどを利用することになります。

ここで、EKSの各特徴をECSに比べた観点で並べてみた表がこちら。

	ECS	EKS
コンテナのIAM制御	タスクへのIAMロール付与	公式未提供（OSSのkube2iam, kiam）
スケジュール実行	スケジュールタスク	なし（Scheduler）
セキュリティグループ	サービスへの付与	EC2で自前管理
監視	CloudWatch統合	なし（Datadog、Prometheus）
ログ	CloudWatch Logs統合	Fluentd
デプロイ	CodePipeline統合	自前構築（helm, kustomize, spinnaker）

コンテナのコントロールプレーンとしては、ECSよりもKubernetesのほうがはるかに自由度が高く高性能といえますが、マネージド未提供なものが多いです。

EKSを採用するときは、この点を真っ先に知っておく必要があります。

Fargateとは

サーバーやクラスターを一切管理することなくコンテナを実行できます。

仮想マシンのクラスターのプロビジョニングが不要
ECSおよびEKSに対応したコンピューティングエンジン
コンピューティングリソースに対しての料金としてはEC2より割高（1割〜2割）

EC2オンデマンドに比べて、ランニング費用は割高ですが、以下のメリットを享受できます。

ホストインスタンスの管理が省けること
EC2の余剰リソースが不要
セキュリティはAWS側で常にカバー
オートスケールの設定も不要

この概念を、ごっつわかりやすい図で表したのがこちら。

（引用元：https://www.slideshare.net/AmazonWebServices/operational-excellence-with-containerized-workloads-using-aws-fargate-con320r1-aws-reinvent-2018/40）

管理コストを氷山で表しています。水面から出ていて目に見える部分のコスト（ランニング費用）は、Fargateのほうが大きいですが、目に見えない運用上のコスト（スケーリング設定、セキュリティ管理、インスタンス管理）は、EC2のほうが圧倒的にでかい、ということです。

また、気になるランニング費用も先日のアップデートで、大幅に下がりました。是非利用を検討してみてください。

【全世界のFargateファンに朗報】Fargate利用料が35%〜50%値下げされました！｜ DevelopersIO

後悔しない選択をする

最後、これらのAWSサービスから最適なコンテナサービスを選択する方法をお伝えします。

単純です。まずは、これを使ってください。

Fargateは、EC2を隠蔽することでコンテナの管理〜運用に特化することができる素晴らしいサービスです。最初に検討すべきなのは、Fargateであると断言します。

ただ、ECS on EC2と比べてFargateではできないこともあるので、注意が必要です。

ホストインスタンスにSSHログインできない
ホストインスタンスにSSHログインしてコンテナの状況を確認するコマンドが利用できない（docker ps、docker images、docker logs、docker execなど）
ログドライバがawslogsのみ
標準ではCloudWatch Logsのみに出力される
（Fluentdは将来対応予定）
EFSが利用できない
複数タスクで同一のローカルリソースを共有することが現状無理
S3などを利用できないか検討する
スポットインスタンスが使えない
EC2でオートスケール部分をスポットインスタンスを使うことでコスト削減するなどの方法が使えない
ホストインスタンスに導入する前提のセキュリティソフトが利用できない
コンテナ単体でセキュリティをチェックする仕組みが必要
GPUインスタンスなど、リソース最適化されたEC2インスタンスが利用できない
Windowsコンテナが利用できない